Summary

• extract the getNamedBackups facade out of lib/storage.ts on top of the latest storage leaf
• keep named backup listing behavior unchanged while slimming the storage facade
• add a focused test for the new named backups entry helper

Validation

• npm run typecheck
• npm run lint -- lib/storage/named-backups-entry.ts lib/storage.ts test/named-backups-entry.test.ts
• npm run test -- test/named-backups-entry.test.ts

note: greptile review for oc-chatgpt-multi-auth. cite files like lib/foo.ts:123. confirm regression tests + windows concurrency/token redaction coverage.

Greptile Summary

this pr extracts the getNamedBackups facade in lib/storage.ts into a dedicated lib/storage/named-backups-entry.ts module, following the same dep-injection pattern already used by restoreAccountsFromBackupEntry. behaviour is unchanged; the extraction improves testability and keeps storage.ts slimmer.

• lib/storage/named-backups-entry.ts — new thin entry that calls collectNamedBackups via fully injected deps (getStoragePath, collectNamedBackups, loadAccountsFromPath, logDebug)
• lib/storage.ts — getNamedBackups is now a one-liner delegating to getNamedBackupsEntry; dep wiring is correct
• test/named-backups-entry.test.ts — focused vitest case asserting all four deps are wired correctly and the return value propagates; adequate coverage for this pass-through layer
• one style nit: named-backups-entry.ts imports NamedBackupSummary from ../storage.js (the parent facade) rather than from ./named-backups.js where the interface is actually defined — recommend fixing to break the apparent type-level cycle

Confidence Score: 5/5

• safe to merge — no behavioural change, correct dep wiring, one cosmetic import nit
• the refactor is a pure structural extraction with no logic change. dep injection pattern matches the existing restoreAccountsFromBackupEntry precedent. the single test is sufficient for a pass-through facade. the only flag is the import type sourced from the parent facade rather than the sibling definition — a p2 style issue that doesn't affect correctness or runtime behaviour.
• lib/storage/named-backups-entry.ts — fix the NamedBackupSummary import source

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant caller as caller
    participant storage as lib/storage.ts<br/>getNamedBackups()
    participant entry as lib/storage/named-backups-entry.ts<br/>getNamedBackupsEntry()
    participant nb as lib/storage/named-backups.ts<br/>collectNamedBackups()

    caller->>storage: getNamedBackups()
    storage->>entry: getNamedBackupsEntry({ getStoragePath, collectNamedBackups, loadAccountsFromPath, logDebug })
    entry->>entry: getStoragePath() → storagePath
    entry->>nb: collectNamedBackups(storagePath, { loadAccountsFromPath, logDebug })
    nb-->>entry: NamedBackupSummary[]
    entry-->>storage: NamedBackupSummary[]
    storage-->>caller: NamedBackupSummary[]

This is a comment left during a code review.
Path: lib/storage/named-backups-entry.ts
Line: 1

Comment:
**import `NamedBackupSummary` from its origin, not the parent facade**

`NamedBackupSummary` is defined in `./named-backups.ts` (right next to this file). importing it through `../storage.js` creates an apparent type-level cycle: `storage.ts` imports `getNamedBackupsEntry` from here, and this file imports back from `storage.ts`. it's safe at runtime because it's `import type`, but it's misleading and tighter to source the type where it lives.

```suggestion
import type { NamedBackupSummary } from "./named-backups.js";
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "refactor: extract na..."}